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1 (1) Real Party in Interest 

2 A statement identifying by name the real party in interest is contained in the brief. 

3 (2) Related Appeals and Interferences 

4 The examiner is not aware of any related appeals, interferences, or judicial proceedings which 

5 will directly affect or be directly affected by or have a bearing on the Board's decision in the pending 

6 appeal. 

7 (3) Status of Claims 

8 The statement of the status of claims contained in the brief is correct. 

9 (4) Status of Amendments After Final 

1 0 The appellant's statement of the status of amendments after final rejection contained in the 

1 1 brief is correct. 

1 2 (5) Summary of Claimed Subject Matter 

13 The summary of claimed subject matter contained in the brief is correct. 

14 (6) Grounds of Rejection to be Reviewed on Appeal 

15 The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 

16 (7) Claims Appendix 

1 7 The copy of the appealed claims contained in the Appendix to the brief is correct. 

18 (8) Evidence Relied Upon 

19 Kocher et al., "The SSL Protocol Version 3.0", March 1996, Internet Draft, draft-freier-ssl- 

20 version3-01.txt, pg. 1-60. 

5,931,917 Nguyen 8-1999 



6,167,382 Sparks 12-2000 
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6,643,701 Aziz 11-2003 

6,367,009 Davis 4-2002 



1 

2 (9) Grounds of Rejection 

3 The following ground(s) of rejection are applicable to the appealed claims: 
4 

5 Claim Rejections - 35 USC § 102 

6 

7 The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the basis 

8 for the rejections under this section made in this Office action: 

9 A person shall be entitled to a patent unless - 

1 0 (e) the invention was described in (1 ) an application for patent, published under section 1 22(b), by another filed in the 

1 1 United States before the invention by the applicant for patent or (2) a patent granted on an application for patent by 

1 2 another filed in the United States before the invention by the applicant for patent, except that an international application 

1 3 filed under the treaty defined in section 351 (a) shall have the effects for purposes of this subsection of an application 

14 filed in the United States only if the international application designated the United States and was published under 

1 5 Article 21 (2) of such treaty in the English language. 
16 

17 

18 Claims 1 -3, 4, 11 - 13 are rejected under 35 U.S.C. 102(e) as being anticipated by Aziz 

1 9 et al. (Aziz), U.S. Patent, 6,643,701 . 

20 

21 Regarding claim 1 , Aziz discloses: 

22 generating at the gateway module respective first session identifiers upon receipt of initial 

23 requests from the mobile communication devices at the gateway module and transmitting the first 

24 session identifiers to the application program (8:1 5-22). Herein, Aziz discloses that requests from a 

25 device causes the relay ["gateway module"] to conduct an SSL handshaking session with the server 
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1 ["application program"]. Thus Aziz discloses the establishment of an SSL connection (Aziz, fig. 2:230, 

2 see also fig. 3:330) between two end points (Aziz 8:23, the relay, and the server) and the generation 

3 and transmission of session identifiers ["first session identifiers"] which are sent by the relay to the 

4 server. This is evidenced by the teachings of Kocher for the SSL protocol (Kocher et al., "The SSL 

5 Protocol Version 3.0"). An SSL handshake between two end points begins with the client first 

6 creating and sending a 'Client hello' message to the server, the message comprising a session 

7 identifier (Kocher, pg. 21 , sect. 7.6.1 .2, par. 1 ,2; compare also Aziz 1 :59-63 and 8:23 - the "relay" 

8 and "server" constitute the end points of an SSL connection, or a "client" and "server"). 

9 associating the first session identifiers with corresponding second session identifiers from the 

1 0 application program at the gateway module (8:1 5-33). Again, Aziz shows the use of the SSL 

1 1 protocol. According to protocol, the application program "processes the client hello message and 

12 responds with either a handshake_failure or server hello message" (Kocher, pg. 23, 7.6.1 .3 "Server 

13 hello"). Thus, the application program (Aziz, fig. 3:340) sends session identifiers within a server hello 

14 message ["second session identifiers"] (Kocher, pg. 23, "session_id") to the gateway (Aziz, fig. 

15 3:320). The second session identifiers corresponds in a manner to the first session identifiers, 

16 thereby allowing the gateway module to appropriately manage a potential plurality of concurrent SSL 

17 communications sessions existing between a plurality of clients and the application server (Aziz, fig. 

18 3). 

1 9 wherein respective connections are established between the mobile communications devices 

20 and the application program (Aziz, fig. 3:[300.1 - 300. M], fig. 3:340). 

21 and in response to subsequent communications from the mobile devices to the application 

22 program (Aziz, 7:58-64; 8:25-32), 
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1 while the respective connections between the mobile devices to the application program are 

2 established (Aziz, fig. 3:[31 0.1 - 31 0.M], fig. 3:340) and for communications within the respective 

3 sessions (Aziz has disclosed that these separate sessions between the devices and application 

4 program are for communication, 6:29-44), 

5 transmitting from the gateway module to the application program the second session 



6 identifiers that are associated with the first session identifiers of the mobile devices of the subsequent 

7 communications (Aziz, 8:25-32; Kocher, pg. 19, par. 1,2; Kocher, pg. 24, sect. 7.6.1, "session_id"). 

8 Herein, Aziz discloses that resumed communications (subsequent communications) from a device 

9 result in a SSL session, comprising the sending from the gateway module to the application program 

10 the same session_id value as was previously sent from and stored in memory by the application 

1 1 program. This session_id value, identifying the session to be resumed, corresponds to the second 

12 session identifier sent by the server within the Server hello message during the initial establishment of 

13 the session. 



14 Regarding claim 2, Aziz discloses: 

1 5 receiving requests of a first type from the mobile devices at the gateway module and 

1 6 transferring the first type requests to an authentication module that manages user authentication 

17 (8:66-9:5); 

1 8 and when a user at a mobile device has not logged-in to the authentication module, 

1 9 transmitting a log-in prompt from the authentication module to the mobile device in response to a 

20 request of the first type from the mobile device (9:3-5,23-29). Herein, Aziz discloses that when the 

21 server requires client authentication, the server requests (the client is prompted) that the client 

22 transmit log in information. 
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1 Regarding claim 3, Aziz discloses: 

2 generating at the authentication module respective authentication identifiers for the first 

3 session identifiers and associating the authentication identifiers with corresponding first session 

4 identifiers (2:1 1-15, 31-36; 8:66 - 9:5,23-29). Herein, Aziz discloses that resulting at the 

5 authentication module ("generating"), are authentication identifiers associated with the identifiers of 

6 the session. 



7 Regarding claim 4, it is the apparatus implementing the method of claim 1 , and it is rejected, at 

8 least, the same reasons. 

9 Regarding claims 11 - 1 3, they are system implementing the method of claims 1 - 3, and they 

10 are rejected, at least, for the same reasons. Furthermore, Aziz discloses a "mobile interface", an 

1 1 interface to connect with a plurality of mobile devices (fig. 3). 
12 

1 3 Claim Rejections - 35 USC § 103 

14 

15 The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 

16 rejections set forth in this Office action: 

17 (a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 

18 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the 

1 9 subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill 

20 in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the 

21 invention was made. 
22 

23 
24 

25 Claims 5 and 10 are rejected under 35 U.S.C. 103(a) as being unpatentable over Aziz in 

26 view of Davis et al. (Davis), U.S. Patent 6,367,009. 

27 
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1 Regarding claim 5, it is a method substantially similar to the method of claim 1 , and it is 

2 rejected, at least, for the same reasons. Furthermore, Aziz discloses applications of client - server 

3 technology within e-commerce and banking systems. Thus, Aziz makes clear that sessions between 

4 clients and a server are sessions between clients and a "merchant" application (1 :40-55). Additionally 

5 Aziz, discloses that client devices can be wireless devices such as cell phones (7:4-18). However, 

6 Aziz does not explicitly disclose that a wireless device would establish a session with the gateway 

7 using wireless means, and therefore, that session identifiers are associated with wireless sessions. 

8 Davis, in a substantially similar disclosure as Aziz, discloses that a wireless device (client) can 

9 utilize its wireless functionality to establish wireless sessions (fig. 3; 7:30-39, 8:44-67). 

1 0 It would have been obvious to one of ordinary skill in the art to employ the teachings of Davis 

1 1 within the system of Aziz. This would have been obvious because one of ordinary skill in the art 

12 would have seen logical the use of a wireless device to establish a wireless session. Thus, the 

1 3 combination of Aziz and Davis discloses the use of a wireless device to establish a SSL session 

14 wirelessly, and therefore, that the session identifiers would be wireless session identifiers. 



15 Regarding claim 10, it is the apparatus implementing the method of claim 5, and it is rejected, 

16 at least, the same reasons. 
17 

18 Claims 6-9 are rejected under 35 U.S.C. 103(a) as being unpatentable over the 

19 combination of Aziz and Davis, in view of Sparks et al., "Design and Production of Print 

20 Advertising and Commercial Display Materials Over the Internet", U.S. Patent 6,167,382. 

21 Regarding claim 6, the combination of Aziz and Davis does not disclose receiving checkout 

22 requests from the wireless communication devices at the gateway module and transferring the 
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1 checkout requests to a wallet module that manages user authentication. Instead, the combination of 

2 Aziz and Davis discloses a generic system for establishing communications between a client and a 

3 server via a gateway (Aziz, figs. 2 and 6). The client and server each establish a secure session 

4 connection with an intervening relay. The relay then enables communications between the client and 

5 the server. The combination of Aziz and Davis discloses that this system is used as an improvement 

6 to various publicly available systems such as electronic commerce and shopping systems where the 

7 authentication and encryption of information is necessary (Aziz, col. 1, lines 42-47; col. 3, lines 1,2). 

8 However, it was not the purpose of the combination of Aziz and Davis to discuss the methods and 

9 features specific to the e-commerce and shopping systems. Thus, the combination of Aziz and Davis 

10 does not disclose methods such as receiving checkout requests, transmitting payment options, or 

1 1 using wallet identifiers. 

12 Sparks discloses a system that features the electronic commerce methods of receiving 

13 checkout requests, transmitting payment options, and using wallet identifiers (Sparks, col. 2, lines 36- 

14 49; col. 17, lines 12-26). 

1 5 It would have been obvious to one of ordinary skill in the art to combine electronic commerce 

16 features, such as those disclosed by Sparks, with the generic system of the combination of Aziz and 

17 Davis for establishing communications because it is obvious that a generic system designed to 

18 enhance electronic commerce (Aziz, col. 1, lines 42-47) would need to features to enable electronic 

19 commerce. 

20 Thus, the combination of Aziz, Davis, and Sparks discloses: 

21 receiving checkout requests from the wireless communication devices at the gateway module 

22 and transferring the checkout requests to a wallet module that manages user authentication (Sparks, 
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1 col. 2, lines 36-49; Aziz, fig. 2; Sparks, Abstract, lines 6-9; 5:41-43; 16:57-67). Herein, the 

2 combination enables for a client device to send checkout requests that are received at the gateway 

3 module and transferred to a e-commerce server application which receives the checkout requests 

4 and authenticates the buyer [thus, a "wallet module"]. 



5 when a user at a wireless communications device has logged-in to the wallet module, 

6 transmitting payment options from the wallet module to the wireless communications device in 

7 response to a checkout request from the wireless communications device (Sparks, figs. 3, 4, 9, 59, 

8 60); 

9 when a user at a wireless communications device has not logged-in to the wallet module, 

1 0 transmitting a log-in prompt from the wallet module to the wireless communications device in 

1 1 response to a checkout request from the wireless communications device (Sparks, figs. 3, 4). 

12 Regarding claim 7, the combination of Aziz, Davis, and Sparks disclose: 

1 3 generating at the wallet module respective wallet session identifiers for the wireless session 

1 4 identifiers and associating the wallet session identifiers with corresponding wireless session 

15 identifiers in a wallet session identifier table (Sparks, figs. 21 - 23). 

16 Regarding claim 8, the combination of Aziz, Davis, and Sparks disclose: 

1 7 in response to a payment request from a wireless communications device, transmitting the 

1 8 payment request from the gateway module to the merchant application (Sparks, col. 1 0, lines 37-64; 

19 Aziz, fig. 2); 

20 disassociating the wireless session identifier from the corresponding merchant session 

21 identifier (Aziz, col. 2, lines 57-67; col. 6, lines 45-55). Unless session resumption procedures have 
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1 been initiated by the client or the server, the session identifiers of the client are not re-associated with 

2 the corresponding session identifiers of the server, therefore, they are disassociated. 

3 generating a new wireless session identifier for the wireless communications device when 

4 another initial request is received from the wireless communications device (Aziz, col. 6, lines 45-55). 

5 New sessions can be requested by the client. 

6 Regarding claim 9, the combination of Aziz, Davis, and Sparks implies clearing inactive entries 



7 from the wallet session identifier table. Electronic systems are not limitless in means for storage and 

8 operation. If unnecessary information was never cleared from memory, eventually such systems 

9 would reach their limits of storage. Therefore, it would have been obvious to one of ordinary skill in 

10 the art to clear inactive entries from the table in order to free and efficiently use a limited amount of 

1 1 memory. 
12 



13 Claim 1-13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Nguyen et 

14 al. (Nguyen), "System, Method, and Article of Manufacture for a Gateways System 

15 Architecture with System Administration Information Accessible from a Browser", U.S. Patent 

16 5,931,917 in view of Davis et al. (Davis), U.S. Patent 6,367,009. 

17 Regarding claim 1, Nguyen discloses: 

1 8 generating at the gateway module respective first session identifiers upon receipt of initial 

19 requests from the communication devices (63:32-34,38-40 - notice initial requests from 

20 communication devices) at the gateway module and transmitting the first session identifiers to the 

21 application program (fig. 20c:2010; 65:28-48 - notice generated first session identifiers uniquely 

22 identifying an individual transaction that has been submitted by one of the communication devices); 
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1 associating the first session identifiers with corresponding second session identifiers from the 

2 application program at the gateway module. Second session identifiers from the application (fig. 

3 20:2005; 61 :4; 65:59-63 -TIDs are issued by the bank) are associated with the first session identifiers 

4 (fig. 20C:2010, see also 64:36-38) which are generated by the gateway to uniquely represent a 

5 corresponding transaction request received from a client. 

6 wherein respective connections are established between the communications devices and the 

7 application program (fig. 22). 

8 and in response to each subsequent communication from each device to the application 



9 program via the connection between the device and the application program while the connection is 

1 0 established, transmitting from the gateway module to the application program the second session 

1 1 identifier that is associated with the first session identifier of the devices of the subsequent 

12 communication (19:4-9; 20:10-22). 



13 Regarding claim 1 , the examiner notes that Nguyen does not explicitly state that 

14 communication devices may be described as mobile. However, Nguyen makes clear that a user may 

15 employ any computing device from any location in the world for the purpose of conducting 

16 commercial transactions (63:32-38). 

17 Davis discloses that it was well known in the art for users to employ mobile computing devices 

1 8 to conduct commercial transactions (1 :48-66; 8:44-67). It would have been obvious to one of ordinary 

19 skill in the art to recognize the teachings of Davis for mobile computing devices within the teachings 

20 of Nguyen for any computing device. This would have been obvious because one of ordinary skill in 

21 the art would have been motivated to employ known and useful methods of prior art. 
22 
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1 Regarding claim 2, the combination discloses: 

2 receiving requests of a first type from the mobile devices at the gateway module and 

3 transferring the first type requests to an authentication module that manages user authentication; and 

4 when a user at a mobile device has not logged-in to the authentication module, transmitting a log-in 

5 prompt from the authentication module to the mobile device in response to a request of the first type 

6 from the mobile device (figs. 28, 29, 31 ). 



7 Regarding claim 3, the combination discloses: 

8 generating at the authentication module respective authentication identifiers for the first 

9 session identifiers and associating the authentication identifiers with corresponding first session 

10 identifiers (88:24-44). 

1 1 Regarding claim 4, it is the apparatus implementing the method of claim 1 , and it is rejected, at 

12 least, the same reasons. 

13 Regarding claim 5, it is rejected, at least, for the same reasons as claim 1 , and furthermore, 

14 because the combination discloses the use of wireless communications between system elements 

15 (Davis, 1:48-66; 8:44-67). 

16 Regarding claim 6, the combination discloses: 

1 7 receiving checkout requests from the wireless communication devices at the gateway module 

1 8 and transferring the checkout requests to a wallet module that manages user authentication (Nguyen, 

19 fig. 28:2830, 2850-2882); 

20 when a user at a wireless communications device has logged-in to the wallet module, 

21 transmitting payment options from the wallet module to the wireless communications device in 
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1 response to a checkout request from the wireless communications device (Nguyen, fig. 

2 27:2708,2704); 

3 when a user at a wireless communications device has not logged-in to the wallet module, 

4 transmitting a log-in prompt from the wallet module to the wireless communications device in 

5 response to a checkout request from the wireless communications device (Nguyen, fig. 31 ). 

6 Regarding claim 7, it is rejected, at least, for the same reasons as claims 2 and 3. 

7 Regarding claim 8, the combination discloses: 

8 in response to a payment request from a wireless communications device, transmitting the 

9 payment request from the gateway module to the merchant application (Nguyen, fig. 3, 28); 

1 0 disassociating the wireless session identifier from the corresponding merchant session 

11 identifier (66:25-30), 

1 2 generating a new wireless session identifier for the wireless communications device when 

1 3 another initial request is received from the wireless communications device (see the above claims for 

14 repeating the disclosed process). 

15 Regarding claim 9, the combination discloses: 

16 clearing inactive entries from the wallet session identifier table (Nguyen, 66:25-30, 53-60). 

17 Regarding claim 10, it is rejected, at least, for the same reasons as claims 1 and 5. 

1 8 Regarding claims 11 - 1 3, they are system implementing the method of claims 1 - 3, and they 

19 are rejected, at least, for the same reasons. 
20 

21 
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1 (10) Response to Argument 

2 

3 Appellant's arguments filed 2/28/2008 have been fully considered but they are not persuasive. 

4 Appellant asserts or argues primarily that: 
5 

6 (i) That is neither Aziz nor Kocher teaches or suggests the second session identifier, which the 

7 application provided to the gateway, is transmitted back to the application from the gateway for the 

8 subsequent communications. (Brief, pg. 15, par. 1) 

9 In response, the examiner respectfully notes that the during the server-client ssl handshake 

10 (e.g. for the initiation of an SSL session), the server sends a session identifier within a 'Server hello 

1 1 message' so as to identify a communication session (Kocher, pg. 23, sect. 7.6.1 .3 - pg. 24, 

12 "session_id"). When the gateway resumes this communication session, it sends the same session 

13 identifier, as was sent by the server within the 'Server hello message', within a 'Client hello message' 

14 (Kocher, pg. 19, par. 1,2). Thus, the examiner points out that the prior art does disclose transmitting 

15 from the gateway module the second session identifier back to the application program. 
16 

1 7 (ii) Thus, the client does not send a hello message for each subsequent communication between 

1 8 the client and the server. Hence, once the two different secure connections are established between 

1 9 the client and the relay and between the relay and the server respectively, hello messages are not 

20 exchanged for each subsequent communication from the client. Thus, Aziz fails to teach in response 

21 to each subsequent communication from each mobile device to the application program, while the 
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1 connection is established, transmitting from the gateway module to the application program the 

2 second session identifier. (Brief, pg. 15, par. 3) 

3 In response, the examiner respectfully notes, contrary to the assertions of the appellant, the 

4 prior art teaches that subsequent communications over an established SSL link require the initiation 

5 of a session resumption procedure (Aziz, 2:57-61). A session resumption procedure between the 

6 gateway and application program involves the sending of hello messages comprising the session 

7 identifiers (Kocher, pg. 19, par. 1, 2). 
8 

9 (iii) Furthermore, Aziz discloses two different secure connections are established between the 

1 0 client and the relay and between the relay and the server, respectively. Thus, hello messages or 

1 1 session identifiers for the first secure connection and the second secure connection are not 

1 2 associated in Aziz. Hence, Aziz fails to teach "associating the first session identifiers with 

1 3 corresponding second session identifiers from the application program at the gateway module, " as 

14 cited in claim 1. (Brief, pg. 16, par. 1) 

15 In response to appellant's argument that the references fail to show certain features of 

16 appellant's invention, it is respectfully noted that the features upon which appellant bases his 

1 7 argument upon (session identifiers for the first secure connection and the second secure connection 

18 are not associated - i.e. the association of session identifiers for a first secure connection and a 

19 second secure connection) are not recited in the rejected claim(s). Although the claims are 

20 interpreted in light of the specification, limitations from the specification are not read into the claims. 

21 See In re Van Geuns, 988 F.2d 1 1 81 , 26 USPQ2d 1 057 (Fed. Cir. 1 993). 
22 
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1 (iv) Independent claims 5 and 10 recite features similar to claim 1 described above which are not 

2 taught or suggested by Aziz in view of Davis. (Brief, pg . 18, par. 2) 

3 In response, the examiner respectfully notes that the appellant's argument is based upon the 

4 arguments above, and is found to be unpersuasive for the same reasons. 
5 

6 (v) However, there is no apparent element in this portion of Sparks or Aziz that corresponds to the 

7 gateway module at which checkout requests are received or the claimed wallet module to which the 

8 checkout requests are sent. Furthermore, the wallet module and its corresponding claimed features 

9 described above are not taught or suggested. (Brief, pg. 18, par. 3) 
10 

1 1 In response, the examiner respectfully notes that the prior art combination enables for client 

12 devices to engage in electronic commerce, including the issuing of checkout requests to a server 

13 (Sparks, col. 2, lines 36-49). Since all communication from a client device to a server is received by 

14 the gateway module (Aziz, fig. 2, 6), the examiner notes that any checkout requests from a client are 

15 received at the gateway module. Additionally, the prior art combination enables a "wallet module", 

16 that receives checkout requests and authenticates a user via login id and password (Sparks, col. 2, 

1 7 lines 36-49; 5:41-43; 1 6:57-67). 

18 Furthermore, in response to the assertion the wallet module and its corresponding claimed 

1 9 features described above are not taught or suggested, the examiner respectfully notes that 

20 Appellant's arguments fail to comply with 37 CFR 1 .1 1 1 (b) because they amount to a general 

21 allegation that the claims define a patentable invention without specifically pointing out how the 

22 language of the claims patentably distinguishes them from the references. 
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1 (vi) However, there is no apparent suggestion in either of Aziz or Sparks that any disassociation 

2 takes palace in response to a payment request as claimed. (Brief, pg. 1 9, par. 1 ). 

3 In response, the examiner respectfully notes the appellant fails to claim any specific manner or 

4 means of association/disassociation. The prior art teaches that unless session resumption 

5 procedures have been initiated by the client or the server, the session identifiers of the client are not 

6 re-associated with the corresponding session identifiers of the server, therefore, for all intents and 

7 purposes, they are disassociated. (Aziz, col. 2, lines 57-67; col. 6, lines 45-55). 
8 

9 (vii) Thus, the TID field 2005, which is allegedly the claimed second session identifiers, is 

1 0 generated by the POS and not the bank, which is allegedly the claimed application. Hence, Nguyen 

1 1 fails to teach or suggest second session identifiers from an application, as claimed in claim 1. (Brief, 

12 pg.20) 

13 In response, the examiner notes that the appellant's argument appears to be based upon 

14 where the second session identifier of the prior art is generated. The examiner respectfully notes that 

15 "from an application" is not equivalent to 'generated by an application'. In response to appellant's 

16 argument that the references fail to show certain features of appellant's invention, it is noted that the 

17 features upon which appellant relies (i.e., where the second session identifier is generated) are not 

18 recited in the rejected claim(s). Although the claims are interpreted in light of the specification, 

19 limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1 181, 

20 26 USPQ2d 1057 (Fed. Cir. 1993). 

21 The examiner notes that the prior art reveals a system (fig. 20C, similarly fig. 22) disclosing a 

22 plurality of clients (fig. 20C:2000) engaged in a corresponding plurality of customer-institution 
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1 sessions (fig. 20C:2003) with an application (fig. 20C:2004) via a gateway (fig. 20C:2007). Second 

2 session identifiers from the application (fig. 20:2005) are associated with the first session identifiers 

3 (fig. 20C:2010, see also 64:36-38) generated by the gateway to uniquely represent a corresponding 

4 transaction request received from a client. Thus, the examiner notes that the prior art discloses 

5 second session identifiers from an application. 
6 

7 (viii) Claim 1 also recites, "wherein respective connections are established between the mobile 

8 communications device and the application program. " Nguyen fails to teach or suggest establishing 

9 connection between mobile communications devices and the application program. Instead, in 

1 0 Nguyen, the clients 2000 communicate with the VPOS terminal to perform a transaction such as a 

1 1 payment. The VPOS communicates with the bank 2004 on a separate connection 2003 shown in 

1 2 figure 20C. The clients 2000 are not attempting to communicate with the bank 2004, and there is no 

1 3 connection established between the clients 2000 and the bank 2004. (Brief, pg. 21 , par. 1 ) 

14 In response, the examiner respectfully notes that between a client and the bank ("application 

15 program"), there is located a connection (fig. 20C:2003). As the prior art teaches that the connection 

16 exists between the client and the application program, the examiner notes that the prior art teaches 

17 an established connection between mobile communications devices and the application program. 

18 Furthermore, the examiner notes that the prior art teaches that the customer or client is issuing 

1 9 payment or account requests so that the bank will pay the merchant on behalf of the customer. 

20 These requests by the customer are delivered to the bank. Thus, the examiner notes that the client 

21 or customer is in communication with the bank or application program (Nguyen, Abstract; 65:38-47). 
22 
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2 No decision rendered by a court or the Board is identified by the examiner in the Related 

3 Appeals and Interferences section of this examiner's answer. 
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5 For the above reasons, it is believed that the rejections should be sustained. 
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